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Abstract 


Consistency management, the ability to detect, diagnose and handle inconsistencies, is crucial during the devel¬ 
opment process in Model-driven Engineering (MDE). As the popularity and application scenarios of MDE expanded, 
a variety of different techniques were proposed to address these tasks in specific contexts. Of the various stages of 
consistency management, this work focuses on inconsistency fixing in MDE, where such task is embodied by model 
repair techniques. This paper proposes a feature-based classification system for model repair techniques, based on 
an systematic review of previously proposed approaches. We expect this work to assist both the developers of novel 
techniques and the MDE practitioners looking for suitable solutions. 

Introduction 


Model-driven Engineering (MDE) is a family of develop¬ 
ment processes that focus on models as the primary de¬ 
velopment artifact. As models are modified by different 
stakeholders, in a possibly distributed and heterogeneous 
environment, the consistency of the overall MDE environ¬ 
ment must be constantly monitored. Therefore, consis¬ 
tency management 50 64 —which involves various tech- 
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any given set of inconsistencies, there (possibly) exists an 
overwhelming number of repair updates that restore the 
consistency. Yet, since the selection of the most suitable 
repair is ultimately a choice of the developer, approaches 
to model repair must balance the automation level of the 
technique and the need for user guidance in the genera¬ 
tion of the repairs. Some authors 58 advocate the use of 


niques concerned with the detection, diagnosis, fixing and 
tracking of inconsistencies—is essential to MDE. In fact, 
besides being fundamental to preserve consistency as the 
models naturally evolve, the necessity for consistency man¬ 
agement arises during various others MDE activities, like 
meta-model and constraint evolution 18 , model refactor¬ 
ing [^, variability modeling or version merging 


heuristics to tackle the presence of a large search space, 
the need for algorithms with a low computational com¬ 
plexity, and the absence of known optimal solutions. 0th- 
advocate against fully automatic approaches that 
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Although inconsistencies may occur due to mistakes or 
imprudent decisions, the overall impact of the changes 
applied by the developers may not be immediately per¬ 
ceptible, especially considering the complexity of the 
MDE development environment. Moreover, inconsisten¬ 
cies may also reflect conflicting or alternative interpreta¬ 
tions of the requirements or uncertainty and partial knowl¬ 
edge 20 . Thus, developing frameworks should not for- 


ers 

replace the role of the human designer in repairing models. 
According to the latter authors, repairing models should 
be an activity that goes hand in hand with the creative 
process of modeling. To render these tasks more man¬ 
ageable, a variety of techniques has been developed that 
assume a more controlled environment with more concrete 
goals, including change propagation 
nization , bidirectional model transformation 


model synchro- 
or in¬ 


cremental model transformation 24 


65 


bid the introduction of inconsistencies altogether, but tol¬ 
erate them while still providing support for their detec¬ 
tion [^. Notwithstanding, as the development progresses 
and conflicting interpretations converge, so are the models 
expected to evolve to a consistent version, and thus incon¬ 
sistencies must eventually be fixed (or resolved) [^. To 
be manageable, these tasks must be supported by auto¬ 
mated techniques that help the user decide how to repair 
the models so that the consistency of the environment is 
restored. In MDE this amounts to model repair techniques 
that attempt to ameliorate the consistency level of the 
MDE environment by proposing updates to the models. 

One of the main challenges of model repair is that for 


Motivated by this diversity of approaches, this paper 
explores the landscape of model repair techniques and 
proposes a taxonomy for their classiflcation. While such 
surveys have been performed in other areas of MDE, a 
systematic analysis of the design space for model repair 
techniques is still lacking. Following other successful clas¬ 
sifications of MDE techniques (e.g., 11 for model trans¬ 


formation), we present our classiflcation axes as feature 
models [^, diagrams developed with the goal of mod¬ 
eling alternative configurations in software product lines. 
We hope this will aid the MDE practitioner in need of 
model repair techniques—or the developer interested in 
developing novel solutions—in the selection of the tech¬ 
nique he deems best-suited for his particular application 
domain. As proof of concept, we classify and compare 
some modern approaches to model repair under our clas¬ 
siflcation system. Although essential to model repair, we 
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do not focus on the problem of detecting the inconsisten¬ 
cies and their causes, which is sufficiently rich to require 
a dedicated survey itself. Also left out of this survey are 
techniques that circumvent the problem by just forbidding 
the introduction of inconsistencies. 

This paper is structured as follows. Section starts 
by presenting and formalizing the model repair problem. 
Section then defines the feature-based taxonomy under 
which model repair techniques can be classified. This tax¬ 
onomy is used in Section to classify and compare three 
recent techniques for model repair. Lastly, Section dis¬ 
cusses some related work, while Section draws conclu¬ 
sions and final remarks. 



Figure 1: Simplified meta-model for class and sequence 
diagrams. 


2 Model Repair 

This section presents and formalizes the problem of consis¬ 
tency management, focusing particularly on model repair, 
the target of this work. 


2.1 Overview 


In this section we introduce a couple of examples, inspired 
by modern model repair techniques 43 58 60 , that will 


provide an overview of the model repair problem and illus¬ 
trate the vastness of features that consistency management 
techniques may implement. 

While many approaches to consistency management are 
focused on particular kinds of models (e.g. UML dia¬ 
grams), most recent approaches to model repair are meta¬ 
model independent: they allow the user to specify both the 
meta-models using some of the available meta-modeling 
languages like OMG’s Model-driven arehiteeture (MDA) 
or the Eelipse Modeling Framework (EMF). Figure [^de¬ 
picts one such meta-model, for representing very simplified 
class and sequence diagrams. 

Although a meta-model defines which model instances 
are considered well-formed, there are a number of struc¬ 
tural and behavioral properties that cannot be captured by 
meta-models alone. Thus, meta-models are usually anno¬ 
tated with additional intra- and inter-modei constraints 
that restrict the internal structure of individual models 
and their relationship with other models, respectively. Ide¬ 
ally, the user should be allowed to define such constraints. 


typically using MDA’s OCL 54 or some similar constraint 


language. One such constraint over class diagrams is that 
class generalization links must be acyclic. In OCL, this 
can be defined as follows for the meta-model in Fig. 

context Class acyclic_generalization: 

not self.closure(general)->includes(self) 


Consider, as an example, the class diagram from 
Fig. conforming to Fig. depicting a tentative 
first version of the structure of a video on demand 
(VOD) system (inspired by [^), consistent under 
acyclic_generalization. Then, assume that at some 
point one of the developers, maybe oblivious of the whole 



(a) Initial state. (b) Updated state. 

Figure 2: Inconsistency in a class diagram. 


inheritance tree or maybe disagreeing with previous de¬ 
sign decisions, updated the model to the version de¬ 
picted in Fig. by introducing a new generalization 
link (colored red), giving rise to a violation that breaks 
the acyclic_generalization constraint. Since such up¬ 
dates can evidence conflicting interpretations of the re¬ 
quirements, the introduction of inconsistencies should not 
be forbidden but rather detected, diagnosed and resolved 
when deemed necessary. 

Regarding the resolution of inconsistencies, the focus of 
our study, a variety of fixes can be applied depending on 
the stakeholders intentions. However, the available choices 
are also limited by the support provided by the modeling 
framework. For instance, a modeling tool working in an 
online setting could have detected the user operation that 
led to the violation (the introduction of the new generaliza¬ 
tion link), and allow the user to either preserve it or undo 
it. In contrast, offline tools, operating in a state-based set¬ 
ting, would have no such information available, and would 
need to either make an arbitrary choice or present every 
alternative to the user. Other design choices regard how 
the repairs should be presented to the user: should the 
procedure just return the repaired model, or abstract in¬ 
structions to guide the user in the repair process? 

The problem becomes more complex when various con¬ 
straints coexist, which is the common scenario. Consider 
the coexistence of class and sequence diagrams. Besides 
internal consistency of the diagrams, consistency between 
them must also be maintained because some data of the 
two diagrams overlaps: messages refer to operations that 
must be available in the target lifeline’s class. Since we 
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(a) Initial state. 
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(b) Updated state. 


Figure 3: Inconsistency between the diagrams. 


have assumed that both kinds of diagrams share the same 
meta-model (much like UML diagrams), these kind of 
properties can still be defined as regular OCL constraints. 
This one in particular would take the shape: 

context Message message_operation: 
self.target.class.operations-> 

exists(o I o.name = self.name) 

These constraints must coexist with those over the indi¬ 
vidual diagrams. For instance, another constraint that 
must hold in class diagrams is that the operations defined 
within a class must have unique names: 

context Class unique_operations: 
self.operations-> 

forall(x,y I x.name = y.name => x = y) 

The class and sequence diagrams from Fig. are consis¬ 
tent under the constraints that have been defined. How¬ 
ever, after two simultaneous updates over these models 
were performed—the introduction of a new operation and 
a new message (colored red), as depicted in Fig. mu 
violations were introduced for both message_operation 
and unique_operations. 

When attempting to remove the violation of the 
mess age-Operation constraint, the developer should be 
aware of the impact that each of the acceptable repairs 
has on the other constraints. Figure depicts a num¬ 
ber of possible repairs that can be applied to the class 
diagram or to the sequence diagram that remove the 
mess age-operation violation. However, some of these 
updates have (possibly undesirable) side-effects: the re¬ 
pair applied in Fig. also solves the violation caused 
by the unique-operations—a positive side-effect—while 
the repair applied in Fig. introduces a new violation 
by breaking acyclic-generalization—a negative side- 
effect. Either way, it is important that the user is aware 
of these side-effects when choosing the fix to be applied, 
and thus model repair procedures should somehow con¬ 
sider all inconsistencies when generating the repairs. In 


this example it is also manifest that the number of valid 
repairs can quickly become too large for the user to han¬ 
dle. Thus, a variety of techniques have been proposed 
that try to balance the automation provided by the re¬ 
pair procedures and the required user input that reduces 
the number of generated repairs. This input includes, for 
instance, requiring the definition of repair hints for each 
constraint, assigning different priorities to constraints or 
model elements, or even disabling some edit operations. 

As techniques were developed to handle more com¬ 
plex application domains, more specialized mechanisms to 
manage their consistency emerged. Such is the case of 
techniques designed to manage the consistency of models 
spread across heterogeneous modeling frameworks. A clas¬ 
sical example of such scenario is the object-relational map¬ 
ping, concerned with keeping class diagrams consistent 
with relational database schemas, so that data conform¬ 
ing to the former can be persisted in databases conform¬ 
ing to the latter. In such cases, unlike the UML sequence 
and class diagrams of the previous example, overlapping 
information can not be directly detected, and thus ded¬ 
icated mechanisms to define inter-model consistency are 
required, like defining traceability links or consistency re¬ 
lations, as advocated in MDA’s QVT Relations 53 . Ded¬ 
icated to manage inter-model consistency, such techniques 
often disregard intra-model constraints altogether. 

It is easy to envision the complexity of model repair pro¬ 
cedures over a considerable number of models and inter¬ 
related constraints, giving rise to multiple violations and 
an overwhelming number of acceptable repairs. Should all 
violations be removed, a subset of them, or only a certain 
class? Will the repairs introduce or remove other viola¬ 
tions? Will the presentation of the repair alternatives be 
intuitive and manageable by the user? How can the user 
guide the generation of repairs so that they prove useful to 
him? A myriad of solutions has been proposed to address 
these and other problems. The remainder of this paper 
will attempt to shed a light on the design landscape of 
such techniques. 


2.2 Formalization 

In order to properly classify model repair techniques, one 
must first formally define the artifacts which are to be 
analyzed. This section defines such artifacts in an abstract 
way, which are instantiated to particular shapes in the 
following section. 

In this study, the MDE environment is considered to 
consist of a set of k models mi,...,m/c that conform 
to a set of meta-models a fact denoted by 

(mi,..., ruk) U Ml x • • • x Mj^. In practice this product 
of meta-models can be seen as a single composed meta¬ 
model M, to which (mi,..., rrik) (usually abbreviated as 
m) conforms. While M defines the structural consistency 
of model instances, semantic properties must be defined 
by external constraints. Such constraints defined over the 
meta-models entail the notion of consistent environment 
state. We denote the universe of constraints supported 
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(a) Operation wait renamed. 


(b) Operation connect created. 


(c) Generalization link created. 


p: Process I i s: streamer i 




1 : connect 


2 : wait 


I p : Process I i s : streamer i 


2 : connect 


(d) Message 2 : connect removed. 


(e) Message 2 : connect renamed. 


(f) Target of message 2 : connect moved. 


Figure 4: Possible repairs for the inconsistency between the diagrams. 


by a model repair technique by C, from which the set of 
constraints {ci,. •., q} C C can be drawn (usually abbre¬ 
viated as c). 

Prior to being removed, inconsistencies must be de¬ 
tected and diagnosed. Since inconsistencies are introduced 
by the different stakeholders as the models evolve, infor¬ 
mation regarding the performed updates may help the 
checking and repair procedures execute quicker and pro¬ 
duce more accurate results. We denote such updates by 
u ^ which, in general, contain at least information 
about the updated post-state m' G which can be re¬ 
trieved by post{u). For instance, in frameworks that 
record the user’s edit operations, updates may take the 
shape of a pair (m,s), where m is the state of the en¬ 
vironment prior to the update and s denotes the applied 
edit operations. In such cases, the post-state is retrieved 
by applying s to m, i.e., post(m, 5 ) = s{m). If available, 
we denote the operation that retrieves the state of the en¬ 
vironment prior to an update u by pre(i4) G M. Since 
inconsistency is expected to be tolerated during develop¬ 
ment, a pre-state m is not assumed to be fully consistent. 

Given a user update, a checking procedure will test 
whether the resulting state is consistent. Such consis¬ 
tency tests are not necessarily boolean, but may return 
more elaborate reports, like which constraints are being 
broken or the elements involved in the violations. Such 
checking reports can be compared for their “inconsistency 
level”, e.g., when some violations are removed, the envi¬ 
ronment becomes “more consistent” but may still not be 
“fully consistent”. Following the approach proposed by 
Stevens , we assume these inconsistency levels to form 
a partially ordered set (X, □). In general, but not necessar¬ 
ily, this partially ordered set has a least element denoting 
the highest level of consistency for the environment, which 
will be denoted by ±x- 

Definition 1 (consistency checking) A consistency 
checking procedure Check \ ¥C ^ U ^ X calculates 


the inconsistency level i G X for an update u ^ U under 
constraints c QC. 

At certain points during the development process, the 
stakeholders may wish to ameliorate the inconsistency 
level of the environment, by removing some of the detected 
violations. This is precisely the role of model repair pro¬ 
cedures, whose goal is to, at least, decrease the level of 
inconsistency of the environment. Again, these techniques 
may produce repairs in a variety of shapes, whose universe 
we denote by IZ. Although the shape of the repairs IZ is not 
necessarily the same as the updates U, it is assumed that 
from a repair r elZ and the user update u eU that led to 
the current state, a repair update u' e U can be derived 
that applies r to otherwise, the consistency checking 
procedure could not be executed after the application of 
repairs. For instance, if u is simply represented by the 
post-state of the environment after user updates, and r is 
a set of edit operations, the repaired can be retrieved 
by applying the r operations to the u state. We denote 
this operation by r{u) G U. As expected, iiU contains the 
pre-state of the update, then pre{r{u)) = post(14). 

Definition 2 (model repair) A model repair procedure 
Repair \¥C ^ U ^ calculates repairs for an update 
u under constraints c C C. 

We assumed that the repair procedure is able to access the 
checking procedure, and retrieve the inconsistency levels 
X of the states. The generated repairs do not necessar¬ 
ily recover full consistency, although they are expected to 
ameliorate the inconsistency level of the environment. Fig¬ 
ure presents our overview scheme for consistency main¬ 
tenance. User updates u are applied to an existing state 
mo, updates from which the modified state m can be ob¬ 
tained, and to which the checking procedure assigns an 
inconsistency level i. Given an update, and with access to 
the checking procedure, the repair procedure generates a 
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Figure 5: Consistency maintenance scheme. 


set of possible repairs r, which, when applied to result 
in a repair update u' from which the repaired state m' can 
be obtained, and whose inconsistency level i' is expected 
to be at least the same as the one of u. (The pre oper¬ 
ations are greyed out because the updates may not keep 
that information.) 

3 Feature-based Classification 

This section presents the collected classification features 
for model repair approaches, that instantiate the abstract 
artifacts defined in Section [23) the mechanisms available 
to the user to customize them, and the behavior of the 
checking and repair procedures. The features are orga¬ 
nized under the following axes: 




1 

Mandatory feature 


Or group 


A 

1 

Optional feature 


Xor group 


F 


Root feature 

F1 ^ F2 

Requires constraint 


F> 


Reference feature 

F1 => -.F2 

Excludes constraint 


Table 1: Feature definition. 



Figure 6: Model repair features. 


selected). Every feature model has a root feature that is 
always present in every configuration, and may comprise 
reference features which point to other models. Finally, 
feature models may also be annotated with requires and 
excludes constraints that allow cross-tree implications. 

Our feature model that classifies model repair ap¬ 
proaches is depicted in Fig.[^ with Repair Technique as its 
root, and a mandatory child feature for every main clas¬ 
sification axis, referencing a separate and detailed feature 
model. These are explored in the succeeding sections. 


Domain the domain space M and mechanisms to cus¬ 
tomize it; 

Constraint the language of constraints C and mecha¬ 
nisms to define them; 

Update the shape of updates U; 

Check the shape of inconsistency levels I and how they 
are reported by Check; 


3.1 Domain 

The definition of the model space has great implications 
on the applicability of the technique, since it defines which 
model artifacts it is able to handle. Moreover, the mecha¬ 
nisms provided to the user to define such space affect the 
overall flexibility of the technique. The alternatives are 
explored below and depicted in Fig. 


Repair the shape of repairs 7^, the behavior of Repair 
and mechanisms to control it. 

Classification axes are organized as feature models^ hier¬ 
archical models that define the set of valid configurations 
of features that a system may implement. Feature mod¬ 
els are typically represented diagrammatically, as defined 
in Table A child feature may only be selected if its 
parent is also selected. Children features may either be 
mandatory (if the parent feature is selected, so must be 
the child), optional (if the parent feature is selected, the 
child may or not be selected) or arranged in or groups (if 
the parent is selected, at least one feature of the group 
must also be selected) or xor groups (if the parent feature 
is selected, exactly one feature of the group must also be 


3.1.1 Formalism 


Apart from early human-centered approaches, that do 
not propose automated systems to manage consistency 
and consider informally defined artifacts 19 , procedures 


Check and Repair are designed to handle model in¬ 
stances m from M represented using particular for¬ 
malisms. Typical formalisms include logical representa¬ 


tions in some abstract formal specification language 20 


26 

51 57 

,58 61 

62 6 

7,|68 , object-oriented specifica- 

tions 

7 15 21 36 4( 

)l60 i 

33| or the support for relational 

data structures |10 

43 45|69 or graphs [ll|4|[2^|27l|^ 

33 35 37, 

38 48 

70 . The chosen formalism is tightly 


connected with the kind of properties that the technique 
is able to check. For instance, reachability properties are 
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Figure 7: Domain features. 


more easily handled in relational or graph data structures. 
Note that, although related, this feature does not directly 
restrict the technical space on which model artifacts are 
designed (Section [3.1.3[ ), which can be internally converted 
to the underlying formalism. 

3.1.2 Meta-model Independent 

Model repair approaches may aim to be independent of the 
application domain. Such meta-model independent tech¬ 
niques provide the users with mechanisms to define the 
well-formedness rules of the model instances. This task 
may be delegated to different agents of the MDE process. 
For instance, in the ViewPoints framework 20 26 there 
are two well-defined roles: the designer of the viewpoint, 
that defines the meta-model, the constraints and the re¬ 
pair plans, and the owner of the viewpoint, that manages 
the view according to the designer’s rules. Meta-model in¬ 
dependent techniques [^[^[^[^[^[^[4^[4^[^[^[7T] 
are more customizable and have wider applicability than 
those whose meta-model is fixed. Techniques with fixed 
meta-models are designed to act on specific domains, like 
those proposed to manage the consistency of UML dia¬ 
grams specifically 


15 21 40 48 57 60 67 68^. While with 


XMI 35 43 45 , UML 15 21, 

29 I 

|40 48 60 

67 70 , or a 

technique-specific language 57 


. These concrete arti- 


facts are translated by the technique into their represen¬ 


tation in the underlying formalism (Section 3.1.1). 

For meta-model independent techniques, this feature 
also specifies the meta-modeling language through which 
the user should specify the meta-models. Under MDA, 
these are expected to follow the MO F s tandard Mp7 


and those under EMF, Ecor^ [^,36 43 45 

^http://eclipse.org/modeling/emf/ 


61 


techniques may not support standard meta-modeling lan¬ 
guages, and require the user to define them through 


technique-specific mechanisms 58 


If the user is allowed to define or customize constraints 
(Section [3.2.1 ), this feature defines the language in which 
he is able to do so. Typically this amounts to some version 
T5|[T6pl35p^ , that is also prescribed 


ofMDA’s OCL 
in EME, or it can be designed specifically for the tech¬ 
nique [tT] . In techniques with support for inter-model con¬ 


straints (Section [3.2.2 ), standard languages include MDA’s 


QVT [53] standard 43,44 


3.1.4 Bounded 

Techniques may assume a bounded universe of model el¬ 
ements, so that the repair procedure can be more man¬ 
ageably Such is the case of techniques that do not al¬ 
low the creation of new elements, and thus are inherently 
bounded by the elements present in the current inconsis- 
Some techniques rely on bounded 


21,51,69 


tent state 

solvers but guarantee that this is opaque to the user, by 
iteratively introducing new model elements in the uni¬ 
verse (Toll^ . 


more limited applicability, knowing the shape of the model 
artifacts a priori may allow the technique to have im¬ 
proved effectiveness and efficiency. 

3.1.3 Technical Space 

This feature defines the teehnieal spaee in which the user 
is expected to specify the various relevant artifacts. These 
may be built around standard languages/architectures like 
AMT, MDA or EMF^ or other specific to the technique. 
This technical space defines the concrete model syntax 
that the technique is able to process, like XML 49 


3.1.5 Multi-model 

Model repair techniques may be designed with particular 
concerns about inter-model consistency and provide ded¬ 
icated support for multi-model scenarios, in which case 
each state m G AT is comprised by a set of multiple 
model instances. Such is the case of techniques that were 
developed to manage consistency in development environ- 


ments with multiple views 19 


for model synchronization ^ 


27 33 


23 


36 


26 


38 


28 46 52 63 


tional 8||43 and multidirectional transformations 44 


and bidirec- 

By 


Again, 


focusing in inter-model consistency, such techniques often 
disregard the internal consistency of the individual mod¬ 
els, leading to overall inconsistent states. 

In contrast, techniques may be defined to manage the 
internal consistency of a single model, in which case a state 
m consists of a single model instance m. Without dedi¬ 
cated support, these techniques may still handle coexist¬ 
ing models, by merging the various models (and associ¬ 
ated meta-models) into a “dummy” model conforming to 


^Note that the domain being classified is effectively the search 
space available to the repair procedure. 
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a single meta-model, and expressing their seemingly inter¬ 
model constraints with that model’s intra-model rules 


(Section 3.2.2). Such is the case of techniques that man¬ 
age the consistency between different UML diagrams, since 
they share the same meta-model 


15,40 48,60,68 , as in 


customize them [23pl35H37pl45p8l|60l[7T1 . Techniques 
may even provide a set of pre-defined constraints but allow 
the user to extend them [20l|^ or restrict them 


the example from Section 2.1 In this classification system, signer 20 26 


Many frameworks delegate such tasks to a repair adminis¬ 
trator, rendering the process opaque to the software de- 
Techniques that do not allow the user 


such environments are not considered multi-model (nor 
their constraints inter-model). However, depending on the 
context, specifying inter-model consistency as an internal 
constraint may prove to be more cumbersome. Moreover, 
techniques with native multi-model support may provide 
a finer control on how these models are repaired (e.g., 
bidirectional transformations assume that repairs are only 
applied to a single model). Such behavior can be simu¬ 
lated through distinguished constraints (Section 3.2.1)— 
by temporarily introducing a constraint that restricts the 
valuation of one of the models 41 —or through area selec¬ 


44 


to define new rules are typically paired with fixed meta¬ 
model techniques, where both the met a-model and the 
constraints are fixed a priori (techniques for managing 
consistency of UML diagrams being the classical exam¬ 
ple). Nonetheless, some techniques with fixed meta-model 


still allow the user to define additional constraints 60 


tions (Section 3.5.2)—by focusing the repair on a particu¬ 
lar model [^ . 

Controlled Update Approaches with support for mul¬ 
tiple models may only allow the user to update the state in 
a controlled manner, typically only allowing updates over 
a single model [7 27,33 so that the propagation to the 
others is more easily managed. These is common in bidi¬ 
rectional transformation techniques, where the update is 
propagated from one of the models to the other: allowing 
concurrent updates could lead to conflicts that could not 
be resolved. 

Pairwise Techniques may focus on pairwise consistency 
management [zlilliiiiiii, since managing the consis¬ 
tency between only two models is more manageable. Such 
is the case of techniques built over triple graph grammars 
(TGGs) [^27 38 . Pairwise consistency management can 
also be used to render the consistency management of mul¬ 
tiple models more manageable 22p6 . However, not every 
constraint between multiple models can be decomposed 
into a set of binary constraints 


Repair Hints When defining the constraint, the user 
may be required to define hints on how to repair the model 
when such constraint is broken . This contrasts with 

techniques where the repair procedures are automatically 
derived from the constraints. The extreme case occurs in 
rule-based approaches (Section |3.5.1 ) where the user is ex¬ 
pected to specify the actual resolution rules for the incon¬ 
sistencies. Although a laborious and error-prone activity 
that does not provide totality or correctness guarantees, 
repair hints are the more direct way to allow the user to 
control the behavior of the repair procedure, one that is 
tightly coupled with the definition of the constraint. 

Distinguished Techniques may support the definition 
of distinguished constraints that instruct the repair pro¬ 
cedure to focus on certain constraints in relation to oth¬ 
ers. This could allow the user, for instance, to focus on 
intra-model constraints and instruct the repair procedure 
to temporarily disregard the inter-model consistency. Dis¬ 
tinguished constraints usually give rise to composite incon¬ 
sistency levels (Section [3.4.3 ), that report the consistency 
of the environment regarding the different constraints. 

The most common occurrence of distinguished con¬ 
straints arises in techniques that allow the user to select 
a specific violation to be fixed 13 15 16 49 60 . Such 


3.2 Constraint 

The expressiveness of the constraint design space entails 
the class of problems that may be addressed by the tech¬ 
nique, while the ability of the user to customize them 
impacts its general applicability (i.e., the shape of con¬ 
straints c C C and how they are specified in the frame¬ 
work). These design choices are explored below and de¬ 
picted in Fig. For techniques with external checking 
procedures (Section [3.4.1 ), these features are assumed to 
regard the design choices of the associated checker, if iden¬ 
tified by the authors. 


approaches may be more scalable than resolving all in¬ 
consistencies at once by following a spirit of toleration. 
Rule-based approaches typically handle a single violation 
at a time, since the resolution hints are defined per con¬ 
straint 20 j22p9p9p0p8p7p8l[70] . Violation selection is 
only available in techniques whose checking procedure re¬ 
turns at least the set of found violations (Section [3.4.3 ). In 
such cases, the composite report typically assesses whether 
the selected violation was effectively removed, and the im¬ 
pact of that repair over the other constraints of the en¬ 
vironment. Since typical constraint languages like OGL 
do not allow the specification of constraints at the model 
level, violation selection is performed through mechanisms 
internal to the technique. 


3.2.1 Specification 


Similar to the meta-model (Section 3.1.2), techniques may 
either have the constraints hard-coded [1 17 21 30 52 57 


62|[67|[^ or provide the user with mechanisms to define or 


3.2.2 Kind 

General-purpose model repair techniques act on intra¬ 
model constraints, interpreting the environment as a sin¬ 
gle model restricted by internal constraints. Nonethe- 
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Figure 8: Constraint features. 


less, techniques that focus on multi-mo del domains (Sec¬ 
tion 3.1.5) typically support the definition of inter-model 
constraints that relate two or more models. While some 
of these focus on inter-model consistency and disregard 
the intra-model constraints, some approaches do consider 
both kinds of constraints p!5}jT7|[^[4Q|[4^[48|[^ . In such 
cases, the shape (presented below) of the different classes 
of constraint may or not be identical. 



3.2.3 Shape 


The most common means to define intra-model consis¬ 
tency is through the definition of logieal constraints 10 


T3l[T5HT^[^[^[^[^|Ml|4^|4^|^|^|5^|60l|^|67 p9l^ ^ 

These may also be used to define inter-model consis¬ 
tency, assuming they are able to refer to elements from 
different models 20 26 68 . The expressiveness of such 
constraints is typically that of first-order logic, although 
they may be extended with other operators like transitive 
closure to allow the specification of reachability proper- 
ties [^|4^|58)|^|ra 


Approaches built over graph data structures are often 
based on pattern matehing, most of the times enhanced 
with negative application conditions (NACs) (Hilllllil 


29p0p0p^ 


27 


Pattern matching is well-suited to specify 
structural properties but not behavioral ones, and as it is 
not very expressive, some approaches allow the patterns 
to be attached with additional attribute constraints 
or imperative code snippets [^. 

Techniques with dedicated support for inter-model con¬ 
sistency may rely on the definition of a traeeability 

that connects ele¬ 
ments from different models. Constraints 20 23 or pat¬ 
terns may then be defined over the 

traceability links that denote the notion of inter-model 
consistency, although some techniques assume fixed con¬ 
straints over these links 


46 


either be explicitly defined by the user 19 20 22 46 


The traceability links may 
by 


manually indicating which elements correspond to each 
other—or be implicitly introduced either by the repair 
rules or by calculation 63 . The expres¬ 


siveness of such techniques depends on the ability to de¬ 
fine properties over traceability links, like their multiplic- 


Figure 9: Update features. 


29 


Another way to define inter-model consistency is 

8|43|44|47 


ity 

through the definition of eonsisteney relations 
that define which sets of model instances are considered to 
be consistent with each other. Finally, some frameworks 
assume a notion of consistency that is implicitly defined 
by a transformation 31 . This is typical in multi-view 


frameworks with a reference model, from which each view 
is calculated through transformation. 


3.3 Update 

Update features define what information is available to the 
fixing procedures regarding the evolution of the models 
from the previous known state to the current one, i.e., the 
shape of the updates U. These are summarized in Fig. 


3.3.1 State-based 

The simplest techniques are purely state-based^ where the 
repair procedure simply considers the post-state of the up¬ 
date (i.e., the current state of the environment), in which 
case updates from U simply amount to model instances 


m [Tj 

IjlO 13 15 16 29 30 35 36 38 

40 

43l48l4^51 57 

61 68 

69 . Such techniques are not able to detect which 


user actions caused the introduction of inconsistencies. 


3.3.2 Delta-based 

In contrast, delta-based techniques require information re¬ 
garding the user actions that led to the current state. 
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Figure 10: Check features. 


These techniques are able to more easily identify problem¬ 
atic portions of the model, but require the online tracking 
of the applied modifications, which may not be possible in 
heterogeneous and distributed development environments. 
Moreover, they may also improve the overall efficiency of 
the technique, as they allow the identification of which 
rules must be reassessed after the update. 

Some techniques consider a frame condition associated 
with the post-state of the environment that indicates the 
portion of the state that was effectively modified, allow¬ 
ing the procedure to diagnose inconsistencies more effec¬ 
tively [^[^|^[^. Alternatively, techniques may require 
the exact sequence of edit operations that led to the cur¬ 
rent state of the environment [22p3p6||58p7l[70irfT] . Such 
techniques may not even have access to the current state 
of the environment, acting only over the provided edit se¬ 
quence. Delta-based techniques may also be provided with 
the pre-state of the environment (i.e., the state mo prior 
to the user update) in order to more effectively 

determine the impact of user updates. The technique may 
also try to derive the frame or the edit sequence from this 
pre-state, but there is no guarantee that the result will 
exactly mirror the real user actions. These pre-states are 
not necessarily consistent, as we assume that inconsisten¬ 
cies are tolerated throughout the development process. Fi¬ 
nally, techniques may keep the full history of the evolution 
of the environment , in which case the repair 

procedure can access not only the most recent update, but 
also the complete historic. 


3.4 Check 

Check features regard the model repair technique’s re¬ 
liance on the checking procedure, whose design options 
are depicted in Fig. Since consistency checking is not 
the focus of this study, these features only classify the re¬ 
lationship between the checking and repair procedures. 

3.4.1 Checking Mechanism 

Repair techniques may have the checking procedure as an 
internal or external mechanism. The former typically use 
the checking procedure as a fundamental piece in the re¬ 


pair 


procedure [T|[T0l[r7p0l[Mp6pl48p9^^ 


70 , while the latter may rely on external tools to detect 


elements that may be causing the inconsistency 58 69 


While the latter allow the repair procedure to be extensible 
by deploying state-of-the-art checking procedures, the for¬ 
mer typically result in more efficient techniques, since the 
repair technique can exploit the potential of the checking 
procedure. Earlier techniques could also rely on the man¬ 
ual identification of the inconsistencies by the user 


3.4.2 Checkonly 

Typically the checking and repair procedures are distinct, 
and thus the user may execute the technique in eheekonly 
mode, so that he/she is able to simply check the model for 
inconsistencies before proceeding to repair it. While not 
exactly a functionality of model repair techniques, without 
this feature the user is not aware that the model is in need 
to be repaired. In techniques that allow violation selection 
(Section |3.2.1 ) such functionality is fundamental to allow 
the user to inspect the violations occurring in the current 
state. 

Approaches may not have a proper checkonly mode. For 
instance, in rule-based approaches 67 6^ (Section |3.5.1 ) 
the constraint may be simply defined as the pre-condition 
of the resolution rule. Nonetheless, rule-based techniques 
may provide both checking and repair rules [H20p2p7|^ 


70 , some using the checking rules to flag violations whose 
occurrence enables the application of the repair rules 17 


21 36 39 40 48 61 62 . 


3.4.3 Reporting 

Reporting regards the information provided by the check¬ 
ing procedure about the detected inconsistencies, i.e., the 
shape of the inconsistency level X. Techniques may just ex¬ 
pect a basic boolean procedure that simply reports whether 
inconsistencies were found. This is typical for solver-based 
approaches 10 ^ (Section 3.5.1). Techniques may in¬ 
stead expect to know the number of violations occurring 
in the current state [^. Most commonly, the checking 
procedure returns a set of violations detected in the model 
instances [T7||T9l|np0p9p0p8p9l|6^^ , usually con¬ 

taining information regarding which constraint is being 
broken and the model elements involved. Having infor¬ 
mation about individual violations allows the user to se¬ 
lectively apply repairs (Section |3.2.1 ), unlike with less ex¬ 
pressive reports. Techniques may also report a goal that 
must be achieved by the repair procedure. These may 
take the shape of a formula that is suspected to have ren¬ 
dered a constraint false and which the repair procedure 
must make true 58p2 or simply information regarding el¬ 
ements suspect of causing the inconsistency and that must 


20 


be remove d [5l[|69| or missing model elements that must 
be created 


Since the shape of the partial order □ over inconsis¬ 
tency levels is dependent on the shape of these reports, 
this feature is tightly connected with the correctness cri- 
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teria that the repair technique may be expected to follow 
(Section |3.6.2 ). In most cases, there is a single sensible 
partial to choose from. In boolean reports, this is simply 
defined as 

= i ^ i' 


just enforcing that a consistent state does not regress into 
an inconsistent one, with the least element ±x = True. In 
case of the numerical report, this takes the shape 


This partial order does not have a least element but several 
minimal elements: once the selected violation is removed, 
nothing can be done to improve the consistency of the 
environment. Since these techniques cannot be executed 
once the selected violation is removed, this actually entails 
the expected behavior. 

3.5 Repair 


i\zi' = i<i' 

where < is the standard order over naturals, stating that 
the number of inconsistencies at least does not increase, 
with Tx = 0. For the list of violations, this simply takes 
the shape 

i\Zi' = i(Zi' 


These features, depicted in Fig. mi classify the behavior 
of the model repair procedure, including the shape and 
enumeration of the generated repairs, as well as the user’s 
ability to control it. The semantics of the generated repairs 
are explored in the following section. 

3.5.1 Core 


meaning that no new violations are introduced, with Tx = 
{}, the empty set of violations. 


Composite In some approaches, the checking procedure 
reports a composite inconsistency level. These emerge 
from distinguished constraints (Section |3.2.1 ), which are 
independently checked by the procedure. In the most 
typical scenario of violation selection, inconsistency lev¬ 
els X take the shape Xi x X 2 , a pair whose first element 
states whether the selected violation was removed, and 
the second element provides information regarding the 
remainder environment constraints, allowing the user to 
be aware of possible side-effects. Composite reports may 
also arise when the techniques distinguish different classes 
of constraints, for instance intra- and inter-model con¬ 
straints 


45 


In these composite reports there is more than a single 
sensible partial order over each shape of X. If both com¬ 
ponents are deemed equally important, the partial order 
takes the shape of the product order: 


(^l:'^2) Xz X T 12 X 2 


meaning that the inconsistency level is improved if either 
of the components is. The least element of this partial 
ordered set is simply (Tx^, Tx 2 )- Many, however, prioritize 
the amelioration of the first component. One of the weaker 
partial orders in this case is the lexicographic order, under 
which improvements to the first component allow arbitrary 
updates on the second one: 

(ii,i2) E = n 1= i'l V (ii = i'l Ai2 E i' 2 ) 

In such case, the least element is still (i-x^, -Lx 2 )- Alterna¬ 
tively, techniques may prioritize the improvement of the 
first component but disallow damage to the second one. 
This is typical in techniques that forbid negative side- 
effects: the selected violation must be removed but no 
new ones may be introduced in the process. This order 
can be defined as: 

(il, ^ 2 ) X (^1: ^ 2 ) ~ (^1 X i-^ /\ i2 ^ ^2^ ^ (^1 ~ ^2 ~ ^ 2 ) 


This feature classifies the engine underlying the repair gen¬ 
eration procedure. Rule-based techniques [T| p~7|[2Q}|^[^ 


29 39 40 48 52,67 68 70 rely on a set of previously de¬ 


fined rules that are applied whenever an inconsistency is 
detected. While providing full control over the resolution 
of inconsistencies, it puts the weight on the designer that 
must specify how constraints are fixed. Moreover, having a 
fixed set of resolution rules greatly reduces the flexibility of 
the technique. Generative approaches derive their trans¬ 
formation rules from production rules that define what is a 
well-formed model . The classical example 

of such approaches are those based on TGGs, where the 
rules are derived from the grammar productions. 

In contrast, syntactic techniques automatically derive 
repair plans by syntactic analysis of the constraints 


13 


15 16 49 60 . Typically, these repair plans are calculated 


at static-time and then instantiated to concrete model in¬ 
stances at run-time when an inconsistency is found. While 
these techniques may be able to generate repair alterna¬ 
tives without user input, the number of generated plans 
may become overwhelming for the user to choose from. 
Syntactic techniques are also not well suited to deal with 
multiple inconsistencies, nor inconsistencies that affect a 
large portion of the model. 

Search-based approaches interpret model repair as a 
model search problem. These are able to automatically 
find fully-consistent models, but suffer from scalability is¬ 
sues. Moreover, they are well-suited to fix inconsisten¬ 
cies that affect a large portion of the model, like reach¬ 
ability properties. Some approaches rely on off-the-shelf 
solvers 10 23,35 43 69 to search for consistent states. 


These solvers are oblivious of the application domain, 
and may produce unpredictable solutions. In contrast, 
other techniques rely on domain-specific search proce¬ 
dures 51 57 58 that rely on domain-specific knowledge. 


like heuristics and the available edit operations, that allow 
a finer control on the generation of repairs. 

Some hybrid techniques are drawn from more than one 
of these axes. Such is the case of rule-based approaches 
that rely on search-based techniques to calculate repair 
plans from those rules 61 62 . Some earlier approaches 
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Figure 11: Repair features. 


are human-centric^ relying on the user to manually flag 
inconsistencies and propose repairs 


19 , focusing on the 


negotiation and education between different stakeholders. 


Incremental Incremental approaches reuse data from 
previous checking or repair executions, improving effi¬ 
ciency and localization of inconsistencies. Such techniques 
must be typically run in an online setting so that the re¬ 
quired information is preserved between executions. Thus, 
they are also typically delta-based (Section |3.3.2 ) so that 
this information is more easily managed. Incremental- 
ity can be essential to preserve the consistency of the 
environment—as in the case of TGGs (§ ( 231 ^ 1^1^, 
which rely on implicit inter-model traceabilities calculated 
in previous executions—or simply a mechanism to improve 
efficiency—as in the technique from 21 60 , that stores 


the instantiations of the constraints so that inconsistencies 
can be more efficiently checked and repaired. Frameworks 
that record the whole evolution of the model instances 
(Section |3.3.2 ) may also be seen as incremental 
since this history may be used to guide the generation of 
repairs. 



Figure 12: Repair enumeration features. 


any restriction imposed by the enforced semantic proper¬ 
ties) 13 15 16 23 43 49 61. Techniques that are not 


complete may discard interesting repair alternatives or fail 
to repair certain inconsistencies. 


3.5.2 Enumeration 

This feature defines the mechanism through which the 
calculated repairs are selected and presented to the user, 
whose design options are depicted in Fig. 


Since the number of possible repairs may be overwhelm¬ 
ing, to be manageable techniques usually restrict them¬ 
selves to a subset of the acceptable repairs. This may still 


amount to multiple repair options p" 

10 

13 16 20 

23 

30 

35 

36 38 40 

43 

48 491158 

60 

61 


69 

, although some 

are able to select single repairs 

[4 27 33 

40 57 62 

68 71 . 


The means through which these repairs are selected may 
or not have been influenced by the user, as will be shown 
below. 


Complete Techniques that return multiple repairs are 
said to be complete if they return every possible re¬ 
pair within the parameters of the execution (i.e., the 
bounds of the search space, the allowed edit operations and 


Order This feature regards the order through which the 
repair procedure selects the repairs from among those ac¬ 
ceptable. In procedures that return a single repair, this or¬ 
der determines which repair will be selected; in procedures 
that return multiple repair alternatives, it determines the 
set of selected repairs as well as the order in which they are 
produced. This order can be embodied in a distance met¬ 
ric A : Z// x Z// ^ N over updates which the procedure tries 
to minimize. While related to least-change (Section 3.6.4), 
techniques with ordered repair enumeration that are not 
complete are not necessarily least-change, as the minimal 
repair among the generated ones may not be the minimal 
repair overall. 

Although in theory this order always exists for each pro¬ 
cedure, it may not have been defined by the developer of 
the technique, and thus be opaque to the user, rendering 
the procedure unpredictable. Approaches that may not be 
predictable include those that return a single repair with 
a solver-based core, that may be sensible to the transla- 
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tion into its language, or rule-based approaches that pro¬ 
vide no control on how the rule application is selected 
(Section 3.5.1). For instance, in rule-based approaches 
it may be achieved by establishing a priority order for 
the rules |^, which may be hidden from the user. Some 
frameworks with these cores may somewhat circumvent 
the unpredictability problem by generating every available 
repair alternative 


of edit operations to be performed by the user to restore 
consistency. 

Note that the shape of repairs r e IZ is not necessarily 


43 


Other approaches have this order pre-defined, rendering 
the technique more predictable and useful. Typically fixed 
metrics include the graph-edit distance, that counts inser¬ 
tions and removals of model elements, and operation-based 
distances, that count the number of edit steps between two 


the same as the one of updates u eU (Section 3.3). For in¬ 
stance, it is common for rule-based approaches to consider 
state-based updates but produce operation-based repairs. 

Operation-based In operation-based approaches, a re¬ 
pair proposed to the user may take the shape of a re¬ 
pair aetion 


17 20 22 36 38 40 46 48 49 51 63 67 70 71 


models, given a set of valid edit operations (Section 3.5.4). 


consisting of an atomic edit operation (as defined in Sec- 
3^, or of a repair plan 


tion 


58 60 62 , built from the sequential composition of valid 


Parametrizable Allowing users to parameterize the 
distance function A enables them to control the behav¬ 
ior of the repair procedure. One such way to achieve this, 
under graph-edit distance, is to assign different weights to 
different parts of the meta-model |9 58 . This allows the 
user to prioritize changes over certain types of model ele¬ 
ments over others. Alternatively, the weights may me as¬ 
signed directly to the model elements, prioritizing changes 
over concrete parts of the model instances 


edit operations. Note that this feature does not regard the 
enumeration of multiple repair alternatives (Section [3. 5.2 ) 
but rather the shape of each particular alternative. 

Moreover, these repairs may be eonerete 38 

48 71 , which can be directly applied to the model, or 


58 . An ex¬ 


treme form of this feature is in area seleetion, in tech¬ 
niques that allow the user to freeze portions of the model 
instances, as in bidirectional transformation. Instead of 
focusing on the models, the user may instead be allowed 

to control the application of the edit operations (if these 3.5.4 Edit Operations 
are well-defined (Section |3.5.4 )) by attaching them with 


abstraet, requiring input from the user to be instantiated. 
The latter typically occur when some repair edit requires a 
parameter that the fixing procedure is not able (or was not 
designed) to provide, relying instead on the user to define 
it This makes it 

prone for the user to provide a value that does not fix the 
inconsistency, or introduces new ones (which may become 
common as the complexity of the modeling environment 
increases). 


eosts 


10 


12 


Users may also be able to assign 
different priorities over the defined constraints. This pro¬ 
vides the user with more information regarding the impact 
of each possible repair 39 or may be used by the repair 


This feature defines the set of edit operations available 
to the repair procedure to calculate the repair alterna¬ 
tives. For state-based techniques, typically those solver- 


procedure to select repairs that best improve the inconsis¬ 
tency level. Such weights can also be used by the checking 
procedure to return more informative reports. Finally, the 
user may be able to control the procedure by relying on 
some additional meta-data from the environment, like au¬ 


based (Section 3.5.1), this set may be undefined, since the 
repair procedure simply searches for consistent states. 

In rule-based approaches p^ [^[^[^[4Q{[48|[^[^[^ 
, this set amounts to the rules defined in the frame¬ 
work. In contrast, in syntactic and other search-based 
approaches, this amounts to the set of operations avail¬ 


thoring and versioning information 58 


Interactive Techniques may rely on an interaetive dia¬ 
log with the user to refine the set of possible repairs 


able to the procedure to form repair plans (Section 3.5.3). 
These usually amount simply to creation, modification and 
deletion operations 49 , although some do not allow the 


creation of elements 51 


19,23 . This process precedes the actual enumeration of 


repairs to the user, and may have as a goal the retrieval 
of a single resolution from the set of acceptable ones |^. 
This is not the same as providing the user with abstract 
repair plans that he must instantiate posteriorly. 

3.5.3 Representation 

This feature regards the actual shape of the artifacts IZ re¬ 
turned by the repair procedure. Techniques may be state- 
based, and simply return the newly generated consistent 
model |10|33|35|43||M]|68|^ . In such cases, a repair r elZ 
simply amounts to a new state m e M. More elaborate 
procedures may be operation-based, returning instead a set 


Although in many techniques this set of valid edit oper¬ 
ations is fixed , the user may also be allowed to eus- 

tomize it, either by allowing him to define the set of valid 
edits 33 43 or disable some of those predefined. Such is 

and some syn- 


the case in rule-based approaches |4Q{[7Q] 
tactic approaches that generate the repair plans for each 
constraint at static-time ^ ^ . (This can also be 


achieved through external means by assigning high costs 
to edit operations (Section 3.5.2[ )). 

While techniques may use this set of edit operations 
to return operation-based repairs (Section |3.5.3 ) to the 


user 


13 15 21 49 , this is not necessarily the case. For 


instance, techniques may internally use operations to cal¬ 
culate the repaired model but still present state-based re¬ 
pairs 43 61 . 
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Figure 13: Repair semantics features. 


3.6.2 Correctness 


Since the goal of repair procedures is to remove inconsis¬ 
tencies from the environment’s state, they must provide 
some correctness guarantees. In fact, we have already de¬ 
fined model repair (Def. under the assumption this no¬ 
tion can be formalized by a partial order □ over inconsis¬ 
tency levels X. As seen in Section |3.4.3[ most of the times 
the shape of X entails the partial order. The correctness of 
a repair procedure is defined from its behavior in relation 
to this partial order. 


3.6 Semantics 

This axis explores the semantic properties that the repair 
procedure is guaranteed to follow, which are depicted in 
Fig. These properties may be difficult to assess, espe¬ 
cially if dependent on user input, like in some rule-based 
approaches. Thus, we follow a conservative approach and 
only assume properties explicitly referred by the authors 
of the technique. 


Well-behaved A model repair procedure is said to be 
well-behaved if the inconsistency level at least does not 
increase whenever one of these repairs is applied, i.e., 

Vr G RepaiRcI^ • ^(ChecKcR □ CHECKcr(R)) 

This is the minimal correctness behavior expected from a 
repair procedure. For instance, in boolean procedures, this 
means not turning completely consistent environments 
into inconsistent ones. 


3.6.1 Totality 

A technique is said to be total if for every user update 
that results in an inconsistent state, it is able to produce 
a repair (if there is one such repair over the current state). 
This property can be formalized, for a set of constraints c 
and an update u, in the following manner: 


Consistency Improving Consistency improving pro¬ 
cedures guarantee that the state of the environment is ef¬ 
fectively ameliorated, reducing its inconsistency level (un¬ 
less it is already at a minimum inconsistency level). For 
a set of constraints c and update r, this property can be 
specified as: 


{3u' G U • pre(rt') = post(R) A CuECKcu' □ ChecKcr) ^ 
{3r G RepaiRc u) 


Vr G RepaiRc m 

ChecKc r{u) □ ChecKc u V -^3i G X • i □ ChecKc r{u) 


meaning that, if there is an update u' from the current 
state that reduces the level of inconsistency, then the re¬ 
pair procedure will always return a repair alternative. We 
assume that if the updates do not preserve the informa¬ 
tion regarding the pre-state, then pre(R') = post(?x) always 
holds. 

The most simple instantiation of this rule occurs in 
purely state-based approaches with a boolean checking 
procedure. For a model m, it takes the shape: 

{3m' G U • ChecKc m' = True) ^ 

{3r G RepaiRc m) 


meaning that, if there exists a model that is consistent 
under c, the repair procedure will return a model. 

Solver-based techniques are naturally total, as they sim¬ 
ply search for consistent states 10 43 . Rule-based tech¬ 


niques are also total in general, since the detection of the 
inconsistencies is connected to the resolution rule. Syn¬ 
tactic techniques that focus in single violations at a time 
are typically total [4^[^ , while those that consider every 
inconsistency at once may encounter conflicts and fail to 
produce a repair. Approaches with need for repair hints 
may fail if the user-defined resolutions do not restore con¬ 
sistency 


33 


Consistency improving procedures are always well- 
behaved. If there is a single minimal inconsistency level 
Tx, then it can be simplified as: 


Vr G RepaiRc m 

CHECKcr(rt) □ CUECKcUW C}iECKcr{u) = ±x 

Under boolean checking procedures this property de¬ 
generates into fully consistent procedures, defined below. 
Under more expressive checking procedures, like those re¬ 
porting a set of violations, this behavior may occur in tech¬ 
niques that attempt to fix violations until a certain thresh¬ 
old is reached 62 . Under composite inconsistency levels 


(Section 3.4.3) this is common in techniques that are only 
concerned with a certain class of constraints (e.g., tech¬ 
niques dedicated to handle inter-model constraints may 
disregard intra-model constraints), or that support viola¬ 
tion selection but do not enforce the fixing of the remainder 
environment constraints. 


Fully Consistent Procedures are said to be fully con¬ 
sistent if they guarantee that the inconsistency level is 
always reduced to a minimum, i.e., for every update u and 
set of constraints c: 

Vr G RepaiRc u • ^3i G X • i □ ChecKc r{u) 
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Fully consistent procedures are always consistency improv¬ 
ing. In case there is a least element ±x in the inconsistency 
level, the law degenerates into 

Vr G RepaiRcI^ • CHECKcr(R) = _Lx 


The impact of this property depends on the minimal 
elements of the partially ordered set X. For instance, un¬ 
der boolean checking procedures, this amounts to setting 
the result to true, while under procedures that return a 
set of violations, this amount to fixing every violation (in¬ 
cluding possible negative side-effects). This is the typical 
behavior of search-based approaches, that resolve all con¬ 
sistencies at the same time p^[^[4^|57[|61[[^ . Note that 
the definition of correctness is orthogonal to totality. This 
means that procedures that fail to produce repairs are still 
deemed correct. In fact, some techniques enforce correct¬ 
ness by simply failing if consistency is not recovered after 
the repair procedure is executed 

Fully consistent procedures are not necessarily desirable, 
as the model may need to undergo inconsistent states be¬ 
fore fully recovering consistency 


20 


this technique is formalized as follows, for an update u and 
constraints c: 

Vr G RepaiRc u - 

W e1Z' CHECKcr'(R) = C}iECKcr{u) => 

A{r{u),u) < A{r\u),u) 

Meaning that, compared with the repairs that are equally 
consistent, the returned repairs are closer to the cur¬ 
rent state of the environment. In purely state-based ap¬ 
proaches, this degenerates into the following property, for 
a model m and constraints c: 

Vr G RepaiRc m- 

Mr' ell’ CHECKcr(m) ^ CHECKcr'(m) ^ 
A(r(m),m) < A(r'(m),m) 

If the identity of indiscernibles holds for the distance 
function (A(m,m') = 0 = m = m'), then least-change en¬ 
tails stability. Otherwise there are minimal updates other 
than the null update. 


3.6.3 Stability 


4 Classifying techniques 


A technique is said to be stable if for every update that 
does not result in an inconsistent state, it returns null 

For an user update u and con- 
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repairs 

straints c, this property can be formulated as: 


ChecKc u = Xx ^ 

Mr G RepaiRcI^ • post(r(R)) = post(R) 


In purely state-based approaches with boolean checking 
procedures, this degenerates into the following property, 
for a model m: 


ChecKc m = True ^ 

Mr G RepaiRc m • r(m) = m 


Rule-based techniques are naturally stable, as the reso¬ 
lution rules are not applied unless inconsistencies are de¬ 
tected. Techniques are not stable if they apply update 
procedures regardless of the models being consistent 33 


3.6.4 Least-change 


The principle of least-ehange requires repaired models to 
be as close as possible to the original, according to some 
defined model metric A : UxU ^ N (meaning that it must 


not be opaque. Section 3.5.2), possibly customized by the 
user (Section |3.5.2 ). This renders the approach more pre¬ 
dictable to the designer since the set of selected repairs 
is well-defined [^. However, while most approaches in¬ 
formally and loosely approximate this intuition using ad 
hoe or heuristic mechanisms, providing least-change guar¬ 
antees is a complex task (M 12 13 15 16 43 . In general. 


Throughout the paper, the proposed features were sup¬ 
ported with references to various papers, not only as a 
way of providing a rich collection of related work, but 
also to ensure that only literature supported features were 
included in the taxonomy. In this section we attempt 
to validate the proposed features by classifying three re¬ 
cent and very distinct model repair approaches in terms 
of our feature model. The major purpose here is to 
demonstrate that classifying techniques through our fea¬ 
ture model helps in obtaining structured and complete de¬ 
scriptions which allow a better understanding and clear 
comparison of different approaches. Although some fea¬ 
tures may be difficult to assess for a particular technique 
(mainly due to lack of information or ambiguity), we end 
up with quite complete profiles with good taxonomy cov¬ 
erage and, most importantly, drawn from a common view 
point, making similarities and differences more obvious. 
Notice that, for the sake of brevity, in most cases we do 
not mention optional features which do not apply to the 
approach addressed. 

To better illustrate the differences between the tech¬ 
niques, as well as the impact of the design decisions, we 
define a simple running example on which they are ap¬ 
plied. Since we could not access the implementations of 
all these approaches, in order to define our profiles and in¬ 
fer actual repairs, we resorted to the explicit information 
available in the literature and to our understanding of the 
techniques after a thorough study. 

The example (borrowed from ) represents a more de¬ 
veloped version of the VOD system and is composed by the 
class and sequence diagrams shown in Figs. |14a] and |14b] 
respectively. The class diagram captures the structure of 
the system, while the sequence diagram describes the steps 
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first-order logic with transitive closure. Since these con¬ 
straints are defined in the same technical space as the mod¬ 
els and meta-models, rather than being attached to the 
meta-model, they may refer to concrete model elements. 


(a) UML class diagram. 

I u : User I I d : Display I 



1 : select I 


1 

1 


-► 



1 




2 : connect 

1 




- ► 





3 : play 


1 

1 

1 

1 



► 

4 : draw 


1 

1 



◄- 


1 






(b) UML sequence diagram. 

Figure 14: Simple VOD system. 


required in the process of playing a movie. Recalling con¬ 
straint message_operation from Section [2.1[ in order for 
this model to be consistent, for every message in the se¬ 
quence diagram, there must exist an operation in the class 
of the receiver lifeline, whose name equals that of the mes¬ 
sage. Since there is no operation play in class Streamer, 
and display d sends message play to streamer st, this 
model is inconsistent. We only consider this single con¬ 
straint in isolation, the repair space not being subject to 
any other restrictions, for instance related to some state 
diagram or to the associations between classes. 

4.1 The Badger Approach 

Badger is a regression planner, implemented in 

Prolog, that generates repair plans for resolving design 
model inconsistencies by applying the artificial intelli¬ 
gence technique of automated planning. This technique 
aims to generate sequences of actions that lead from an 
initial state to a state meeting a specific predefined goal. 
Requiring as input a model and a set of inconsistencies. 
Badger performs a regression planning by starting from 
the negation of these inconsistencies as the goal state, 
and searching backwards to find a sequence of actions 
that reach the initial state. 


Domain Badger is based on a logieal formalism, as mod¬ 
els and met a-mo dels are represented by logic facts, spec¬ 
ified in a Prolog embedded Domain Specific Language 
(eDSL). The technique provides rules for defining meta¬ 
model elements, their properties and relationships, thus 
being meta-model independent. However, having the Pro¬ 
log eDSL as its teehnieal spaee {other), it does not pro¬ 
vide any automated mechanism to allow the embedding of 
models nor meta-models persisted in standard languages. 

Constraint Similarly, constraints are user definable in 
the eDSL as intra-model logieal constraints expressed in 


Update In Badger, models and updates are indistin¬ 
guishable since they are not represented by the elements 
they contain, but rather by sequenees of edit operations. 
The entire history reeord is kept (thus each pre-state also), 
with authorship and versioning information attached to 
each edit step. 

Check For detecting inconsistencies. Badger relies on 
the external checking procedure proposed in , which re¬ 
turns model-level predicates corresponding to existing in¬ 
consistencies. These predicates are then required by the 
repair procedure for specifying a goal state which negates 
them. 


Repair Prolog’s built-in backtracking mechanism al¬ 
lows Badger to generate multiple repair plans, each one 
consisting of a set of repair actions that renders the goal 
true. The tool is a domain-speeifie planner based on a 
recursive best-first search (RBFS) algorithm. Although 
this is an improvement of the well-known A* algorithm, 
which is known to be complete, it is not clear in the 
paper whether Badger provides a complete enumeration 
of plans or not. Badger has a fixed set of edit operations 
for creating and deleting objects, as well as for creating, 
modifying and deleting properties or references on those 
objects. The repair procedure enumerates the repair 
plans under a parametrizahle order, which the user can 
control by tweaking the cost function used by the planner 
algorithm. For instance, the metric can be parameterized 
by assigning eosts to edit operations, or weights to 
meta-model and model elements. Area seleetion and 
operation disabling can be achieved by assigning infinite 
costs. Since it keeps the whole history record, costs 
over meta-data such as authors and versions can also be 
assigned. In order to avoid the multiplication of resolution 
plans, for modifying references only (other operations are 
eonerete). Badger resorts to temporary {abstraet) ele¬ 
ments which the user must replace by concrete ones when 
effectively applying the repair. Concerning semantics. 
Badger applies a eonsisteney improving procedure as it 
generates plans transforming the erroneous model into a 
model which does not have the detected inconsistencies 
(negated in the desired goal). It is not, however, fully 
consistent, since other violations may arise (negative 
side-effects). Finally, the solution function used by 
Badger, which verifies whether there are no more un¬ 
satisfied literals in the desired goal, should ensure stability. 


By default, the generated plans are ordered in terms 
of the number of actions they contain. For the example. 
Badger generates the following eight plans to resolve the 
violation 
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1 . 

2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 


modify reference target of message play 

set property name of message play to stream 

set property name of operation stream to play 

set property name of message play to wait 

set property name of operation wait to play 

set property name of message play to connect 

set property name of operation connect to play 

delete message play and its references souree and 
target 


Alternative cost functions change the order in which res¬ 
olution plans are generated (disabling some if infinite costs 
are assigned). For instance, if one were to set a higher pri¬ 
ority to the sequence diagram by assigning smaller costs to 
actions that create, modify or delete an element belonging 
to it, the order in which these plans would be generated 
becomes 1, 2, 4, 6, 8, 3, 5 and 7. 

The first generated plan, which suggests modifying ref¬ 
erence target of message play, is an example of an abstract 
repair. It avoids enumerating every lifeline, requiring the 
user to choose one when applying the repair. 

Despite resolving previously detected inconsistencies. 
Badger is not free from negative side-effects. This is 
demonstrated with plan 7, where it repairs message play 
but introduces another violation of the same type for mes¬ 
sage connect. Considering the abstract syntax presented 
in its paper for the class and sequence diagrams, as well 
as all the types of repair actions supported by Badger^ 
the list of plans does not appear complete. For instance, 
adding the missing operation to class Streamer or modi¬ 
fying reference elass of st, would also be valid repairs. 


4.2 The Model/Analyzer Approach 

The Model/Analyzer is a tool which follows an 

incremental approach to model repair, mainly focusing 
on efficiency. Using the syntactic structure of constraints, 
it determines which specific parts of a model must be 
checked and repaired. To achieve this, a form of profiling 
is used to dynamically observe constraint instances dur¬ 
ing evaluation in order to identify what model elements 
they must assess. Building upon this tracking mechanism, 
once a constraint instance is evaluated, the tool is able to 
generate a corresponding tree of repair actions. 


Domain Model/Analyzer is built over an object-oriented 
formalism, and even though the underlying repair tech¬ 
nique is in theory applicable to any kind of models, the 
tool is implemented for UML (MDA) diagrams only, not 
providing any meta-modelling language. 

constraint instance corresponds to the evaluation of a con¬ 
straint for a particular element of its context. For instance, in the 
example one would have one constraint instance per message. 


Constraint In the shape of intra-model logical rules, 
constraints are user definable by means of a generic lan¬ 
guage, called abstract rule language (ARL), to which it 
is possible to map arbitrary constraint languages, such as 
OCL. Once evaluated, the user is supposed to select a 
specific violation to be fixed, instead of resolving all in¬ 
consistencies at once. 

Update For each instance of each constraint, a consis¬ 
tency tree following its syntactic structure is kept in mem¬ 
ory and dynamically evaluated in response to identified 
model updates (delta-based). When an element changes 
due to a modification in the model, every constraint in¬ 
stance having that element in its evaluation scope is noti¬ 
fied. This works as a frame condition indicating the por¬ 
tion of the state that was effectively changed. 

Check This is an internal checking procedure tightly 
coupled to the repair mechanism. In fact, it is the core of 
this technique, while the repair procedure is built over it 
and thus can be naturally run in checkonly mode. A viola¬ 
tion is reported for each constraint instance that evaluates 
to false, an evaluated tree being returned. Since the in¬ 
volved model elements are localized through their leaves, 
one is able to understand where and why they failed. 

Repair The repair procedure is based on the compari¬ 
son of the expected truth value of each consistency tree 
node, derived from its parent (ultimately, that of the root 
being true), with its actual observed valuation. Wherever 
these values differ, a corresponding repair node is gener¬ 
ated accordingly to the type of consistency node (logical 
operator) and observed valuations. Since there may be 
more than a way to modify the valuation of a logical 
operator, alternative repair plans are returned for each 
violation, consisting of sequences of abstract and fixed 
edit operations (element creation, deletion, and modifi¬ 
cation). This results in repair trees which also follow the 
syntactic structure of the design constraint and represent 
enumerations of multiple repair plans. The approach is 
incremental because once an update is performed, only 
those trees (and tree branches in particular) are evaluated 
which are affected by that particular change. Regarding 
semantics, the repair procedure is consistency improving 
because it fixes those inconsistencies/trees selected by the 
user. Yet, similarly to Badger^ it is not fully consistent 
because other trees may be negatively affected. Besides 
easily ensuring totality^ this approach is also stable, as 
the repair generation only occurs if the truth value of the 
consistency tree is false. 

For the defined example. Model/Analyzer is expected 
to produce seven alternative repair plans, each consisting 
of a single repair action. Here we present the repair tree 
flattened into a set of alternative repairs Notice that, 

'^This is done for conciseness, and possible because the tree would 
only include disjunction nodes. 
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unlike the list of repairs generated by Badger^ here the 
alternative plans are not ordered: 

• modify reference target of message play 

• modify reference tar get.class of message play 

• add operation to tar get.cl ass.operations of message 

play 

• modify property name of message play 

• modify property name of operation stream 

• modify property name of operation wait 

• modify property name of operation connect 


able to check and repair both inter- and intra-model 
consistency. 


Domain Since Echoes kernel is the Alloy model finder, 
it is based on a relational formalism. Both models— 
following the standard structured language XMI—and 
meta-models—defined in EMF^s Ecore met a-modeling 
language—are processed into this formalism, rendering the 
technique meta-model independent. Moreover, Echo has 
support for multi-model environments, so multiple Ecore 
meta-models may be provided. Although its core engine 
is hounded^ the repair procedure, presented below, guar¬ 
antees that this characteristic is hidden from the user. 


Repair plans are generated either to fix the ranges of 
the quantifiers, or their predicates. In the former case, 
a repair action is suggested for each property referenced 
on the range’s expression, while in the latter case, a re¬ 
pair subtree is calculated for each element contained in 
that range. Eor message play in particular, the top three 
plans fix the range of the existential quantifier, while the 
other four repair its predicate. Notice that modifying the 
class of the receiving lifeline, as well as adding an opera¬ 
tion to its current class (respectively the second and third 
plan) are two particular fixes missing in BadgeEs repair 
list. However, compared with that previous technique, 
this approach is instead missing the possibility of deleting 
message play itself. In fact, we did not find any infor¬ 
mation about how Model/Analyzer handles additions and 
removals of context elements, so the repair enumeration 
might not be complete. 

Unlike Badger^ where a plan may suggest a concrete 
value to be assigned to some property, here all repair ac¬ 
tions are abstract. Eor instance, the action suggesting to 
add an operation does not state whether this should be 
created anew or should come from another class, nor any 
suggestion to modify a name reveals what value should be 
used. 

As a given tree is seen in isolation, one repair may ren¬ 
der (once instantiated) another tree inconsistent (nega¬ 
tive side-effect). Eor instance, as Badger also suggests, 
modifying property name of operation connect (last plan) 
can only make message play consistent, if it also makes 
message connect inconsistent. Nevertheless, the authors 
stress that such potential side-effects are detectable by 
checking whether a repair action of a repair tree refer¬ 
ences a model element belonging to the validation scope 
of other trees. 


4.3 The Echo Approach 


Echo is a tool for consistency management based on the 
relational model finder Alloy, developed on top of the 
popular EME. While initially built as a bidirectional 
model transformation framework 


42 43 


evolved to also handle intra-model consistency 
multidirectional transformation 


it eventually 
and 


44 


45 


Thus, Echo is 


Constraint Constraints are user-definable^ either 
through the embedding of OCL intra-model logical 
constraints as meta-model annotations, or by following 
QVT-R, a declarative language designed to specify 
inter-model consistency relations between related models. 
Both these types of constraints are expressed in first-order 
logic with transitive closure, and are also embedded into 
the Alloy core. 

Update Echo is state-based since it simply considers the 
post-state resulting from a user update. While this allows 
the technique to be run offline—since it does not need 
to record the user’s edit operations—this will require the 
procedure to check the consistency of the whole model at 
every execution. 

Check The checking procedure is internal to Echo and 
can be run in checkonly mode: once models, meta-models 
and the constraints are embedded into Alloy, its model 
checking capabilities are used to check the consistency of 
the environment. Thus, the checking procedure is essen¬ 
tially boolean. However, intra- and inter-model constraints 
are distinguished, with Echo testing them independently, 
resulting in a composite checking report. 

Repair The core of the repair procedure is similar to 
that of the checking, but relying instead on Alloy’s model 
finding capabilities. Thus, it automated through the 
use of a solver that calculates new model states that 
satisfy the constraints. Being built over model finding, 
the procedure is naturally complete^ enumerating multiple 
model states. Despite being state-based, the user is 
able to customize the set of allowed edit operations that 
give rise to the calculated states, thus controlling their 
generation. The tool follows the principle of least-change^ 
which is achieved by instructing the model finder to iter¬ 
atively search for models at an increasing distance. Two 
pre-defined metrics are supported by Echo: graph-edit 
distance, that counts insertions and removals of atomic 
model entities, or an operation-based distance that counts 
the number of user-defined operations applied. The 
latter is parametrizable through the definition of the valid 
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edit operations. Finally, due to its core based on model 
finding, this technique is naturally totals fully consistent 
and stable. The trade-off is performance, since this 
procedure does not scale for large models. 


Regarding our example, it was encoded in Echo as an 
inter-model consistency problem to be compared with the 
other approaches. Since Echoes repairs are state-based, it 
returns new model states rather than repair plans. One 
of the consequences is that the user is not directly aware 
of the performed updates. Figure \TE\ shows the repair al¬ 
ternatives for this problem that are closest to the original 
model under regular graph-edit distance. For models at 
the same distance from the inconsistent model, the order 
in which they are returned is arbitrary. Note that only 
fully consistent models are returned (e.g., no alternative 
renames operation connect, as it is being referred by an¬ 
other message). The creation of a new operation and the 
deletion of the message are not among this initial set of al¬ 
ternatives, because they are not at minimal distance from 
the initial model. Nevertheless, once the minimal ones are 
enumerated. Echo starts producing the next closest ones, 
which would include those repair alternatives. Note that 
renaming the connect operation to play and changing 
the class of the st lifeline, although embodying minimal 
updates, are not produced by Echo^ since they create neg¬ 
ative side-effects and would render the environment incon¬ 
sistent. 

The order of the returned solutions could be modified 
by defining the valid edit operations (through OCL pre- 
and post-conditions) and enforcing the operation-based 
distance. For instance, defining only operations to rename 
or delete messages. Echo would only return the models 


from Figs. |15a[ |15b| and |15c[ and one where the message 
is deleted. 


5 Related Work 


Although several taxonomies have been proposed to a vari¬ 
ety of MDE activities, no systematic classification has been 
proposed for model repair specifically. To date, the most 
comprehensive study on consistency management, includ¬ 
ing inconsistency fixing, is still 64 , which, based on pre¬ 
vious definitions from 50 and 25 , surveyed and classified 


the existing approaches. Robust feature-based classifica¬ 
tions have been proposed for model transformation 11 , 
model synchronization and bidirectional transforma¬ 
tion [^. While some features of model repair approaches 
overlap with features from those areas, there are many 
topics that are specific to this domain. 

A feature-based classification of model repair techniques 


was previously presented in 56 , addressing the flexibility. 


usability and extensibility of the approaches. Our classi¬ 
fication largely subsumes that proposal, not only with a 
thorough classification of the behavior of the repair pro¬ 
cedure and on the user’s ability to control it, but also by 
addressing the relationship of such procedures with the 


remainder artifacts of the MDE environment. Our valida¬ 
tion through literature review is also more exhaustive. 

Although our formalization of the semantic properties 
of the model repair procedure is novel, they are inspired by 
those proposed for constraint maintainers in the context 
of bidirectional transformation 
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6 Conclusion 

Inconsistency fixing methods are vital to any development 
process within the increasingly adopted MDE. Resulting 
from an exhaustive and systematic analysis of their di¬ 
verse landscape, in this paper we propose a novel feature- 
based classification system for such model repair tech¬ 
niques, with the intent to aid the MDE practitioner in 
choosing the approach most suitable for his/her particular 
needs, but also the developer interested in developing new 
techniques. Supported by an underlying formalization of 
the problem of model repair, our feature-based taxonomy 
comprises five major classification axis, organized as hi¬ 
erarchical models defining valid configurations of features. 
With a deep focus on the behavior of the repair procedure, 
the shape of all other relevant MDE artifacts was also ad¬ 
dressed, as well as the role of the user in specifying and 
customize them. 

We classify some modern approaches to model repair 
under our classification system, obtaining normative pro¬ 
files which assist in understanding the techniques, and, 
since drawn from a common view point, make similari¬ 
ties and differences more obvious. A comparison is done, 
and the impact of some design decisions demonstrated, by 
applying these techniques to a simple example. 

Although approaches to model repair are rather het¬ 
erogeneous, our experiments show that the proposed clas¬ 
sification is sufficiently flexible to classify most existing 
approaches. Nonetheless, we plan to further refine our 
taxonomy by encompassing new methodologies and rigor¬ 
ously reviewing it as needed, thus ensuring that it remains 
applicable, complete and understandable. 
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(d) Target of message 3 : play moved do d. 


(e) Streamer operation wait renamed to play, (f) Streamer operation stream renamed to play. 


Figure 15: Model repair alternatives generated by Echo. 
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